home *** CD-ROM | disk | FTP | other *** search
- Path: homer.louisville.edu!krsear01
- From: krsear01@homer.louisville.edu (Kendall R. Sears)
- Newsgroups: comp.sys.amiga.misc
- Subject: Re: OS features
- Date: 16 Jan 1996 14:25:44 GMT
- Organization: University of Louisville, Louisville KY USA
- Distribution: inet
- Message-ID: <4dgch8$rkf@hermes.louisville.edu>
- References: <92747544038@PAPA.NORTH.DE> <4b3h9s$1st@alterdial.UU.NET> <m4d20p0mn2v.fsf@freud.hut.fi>
- NNTP-Posting-Host: homer.louisville.edu
- X-Newsreader: TIN [version 1.2 PL2]
-
-
- > >What I propose is a system to segregate the system memory into 3 parts:
- > > 1) an area for the OS that is protected from writes by user processes
- > > 2) an area for user code that is write protected
- > > and
- > > 3) a "public" area where the data segments of programs are stored as well
- > > as message ports, and other data that need to be accessed by multiple
- > > programs.
-
- > Something like MEMF_PUBLIC, MEMF_PROTECTED and MEMF_PRIVATE? I have
-
- Well, sort of. I have monitored several discussions where flags of that sort
- were batted around and in the end, for the sake of compatibility, those were
- rejected. What I was thinking was more along the lines of modifying LoadSeg()
- to put the code segments into protected memory and everything else in a public
- area. Obviously, flags of the above sort would/could be useful for future
- programs.
-
- > been toying around with a similar idea. Code space would be allocated
- > from protected memory space, so that crazed programs could not write
- > over existing code (and self-modifying code works badly
- > anyway). Private data would be specifically protected with the
- > MEMF_PRIVATE flag and the application programmer would know upon
- > writing the code that the data in it cannot be shared with other
- > tasks. Old programs would be given MEMF_PUBLIC-type memory always so
- > that they would continue to work, and crash each other. If the OS
- > contained more checks against rogue pointers we could have a very
- > stable OS with a very high degree compatability.
-
- Very close to what I was saying. Self modifying code is illegal, therefore we
- just don't support it... period. Otherwise, LoadSeg() could put the code
- segments of even old programs into protected memory, as long as the data is
- available then most programs should be unaffected.
-
- > >Obviously, if a rogue program goes tromping through area 3 data could be
- > >corrupted, but correctly written programs check packet validity upon receipt
- > >to their port(s) and should be able to reject bad data, in the case where they
-
- > This means the OS also should be more picky about the data it gets.
-
- Should. If type checking (use the lh_Type/ln_Type fields folks!) were added
- to the OS then things could become more stable, but that's not a guarantee.
- Usually, bad pointers to the OS point to $0 and enforcer has done wonders for
- developers to find those (and also wonders for users to keep the system up!)
- and I don't see why enforcer type protection shouldn't be added to the OS.
-
- > >Obviously, use of the MMU to change the status of memory sections will create
- > >some slowdown, but since most, if not all, changes will occur with a context
- > >switch this probably won't be noticed.
-
- > I bet every serious Amiga programmer would be ready to live with it. I
- > know I would =)
-
- Every programmer I know wouldn't care about a few cycles wasted... especially
- when the cycles wasted are compared to the time wasted to recover from a crash.
- It's the /<0d3rz that have problems with it, but most of them toss out the OS
- anyway.
-
- > >We could even take this a little farther... Assume that an Area 3 is set up
- > >for each process, when a process disappears (for any reason) the OS could
- > >call a DeletePool() on the area to recover most allocated memory (assuming,
- > >of course, that AllocMem() et al. is changed to call the pool functions.)
- > >The OS could either use an age mechanism or a task that occasionally runs
- > >the pools looking for headers that contain ids that no longer exist.
-
- > Resource tracking? Would be fun... I'd also like to see an ability to
- > reduce memory trashing, but this should come "almost free" with a VM
- > solution.
-
- Resource tracking: of a sort. Technically, it's not. To track resources would
- involve listing all screens/windows/layers/temprasts/... and freeing those. My
- method above would not even attempt to close/free screens/windows nor would it
- remove resources from system lists. My method would only free memory held in
- the pools that have (expired|no process) and return that memory to the system.
- It'd be up to Intuition to handle the cases for itself.
-
- Memory trashing: VM really doesn't buy one protection against memory trashing.
- It tends to hide the problem, but eventually, even with VM, physical memory
- will get fragmented to a point where where won't be enough RAM to even swap.
- Of course, the above assumes that one doesn't swap out "public" memory, which
- would be necessary if one doesn't use separate memory maps for each process.
-
- > >This scheme wouldn't keep everything from crashing, nor would it be 100%
- > >compatible, but I believe that it'd work and make the system much more
- > >stable without significant speed penalties.
-
- > I also believe it might work. It might also provide an upgrade path
- > to full memory protection later on.
-
- Much later on. Only after old software has aged to a point where no one uses
- them.
-
-
-